The invention relates generally to bar code scanners, and more specifically, to techniques for interfacing bar code scanners with computers.
For years, various bar code scanner manufacturers have been selling keyboard-wedge bar code scanners. With reference to FIG. 1, bar code scanner 108 is connected to a personal computer (PC) 100 keyboard controller port 104 and a computer keyboard 110 in an Y or wedge type configuration. Bar code scanner 108 may contain an on-board processor 109. PC 100 also contains a processor 101. The Y or wedge type configuration is implemented using interconnection cable 106 such that computer keyboard 110 and bar code scanner 108 are placed in parallel across controller port 104. This parallel configuration is used because keyboard controller 102 circuitry within presently-existing PCs (personal computers) 100 and laptop computers attempts to detect the existence of a computer keyboard 110 connected to the keyboard controller port 104. The controller port 104 needs to be connected to a computer keyboard 110, even if the keyboard is not to be used for subsequent data entry, and even if the controller port 104 is also connected to an input device other than a computer keyboard. If the keyboard controller 102 circuitry does not detect a keyboard connected to the controller port 104, the PC 100 and/or laptop may then disable the port, preventing any further inputting of data. In the operational environment of FIG. 1, this disablement poses a problem, because we desire to input further data as bar codes are detected and decoded.
With the increasing use of laptop computers and keyless data entry, the keyboard controller port shows great potential as a convenient, somewhat standardized, and readily available data input channel. However, this potential could be advantageously exploited only if it were possible to find some way around the necessity of connecting this port to an actual computer keyboard. By way of clarification, there are a number of existing programs that do not require the use of a computer keyboard per se, but these programs have neglected to provide mechanisms by which a computer keyboard is emulated, so as to prevent the controller port from being disabled.
Assume that a conventional keyboard wedge bar code scanner is connected to a keyboard controller port of a PC or laptop, as shown in FIG. 1, while, at the same time, the keyboard that is connected in the parallel (Y) configuration is eliminated. Will the hardware configuration of FIG. 1 still function as desired? It is important to realize that keyboard-to-PC communications is implemented by means of a 2-way channel. Other types of data must be communicated between the PC and the keyboard in addition to information specifying the key or keys that were pressed. When a PC is powered up, the PC is programmed to check for the existence of a primary data input device, which is typically a keyboard. The PC begins a data exchange with the keyboard, and this communication is called xe2x80x9cpower-on diagnosticsxe2x80x9d. If the keyboard is not present, or if the power-on diagnostics fail, the PC will not boot up. Accordingly, if a normal boot-up is desired, the keyboard shown in FIG. 1 should not be eliminated. In the case of laptop computers, a similar situation exists. A communication protocol is used to sense the presence of an external keyboard that is connected to the laptop""s external keyboard port. If the laptop computer fails to detect a keyboard at the external keyboard port, then the laptop computer may disable its external keyboard port.
Even if a technique were to be developed by which a bar code scanner could successfully emulate a computer keyboard, another problem would then arise. Eleven (11)-bit transmission protocols are utilized almost universally to provide keyboard to PC data transfer. The transmission protocol begins with a Start bit (low), followed by 8 data bits, a Parity bit (odd parity) and finally a Stop bit (high). In the context of a computer keyboard, these 8 data bits are used to represent one or more scan codes corresponding to keyboard key presses. However, in the operational environment of FIG. 2, these data bits can be employed to represent all or part of a detected bar code. Irrespective of whether these 8 bits represent actual key presses or bar codes, the aforementioned transmission protocol remains unchanged. The protocol allows the PC (or laptop) to interrupt the transmitted sequence up through the 9th bit. Since the 9th bit can be used to represent all or part of a scan code, the PC will prevent the communication of a scan code if the PC sends out a keyboard port inhibit any time before the 9th bit is received by the port. If the scan code represents all or part of a decoded bar code, upon issuance of a keyboard controller port interrupt, the PC will prevent the successful receipt of this bar code at the keyboard controller port.
The aforementioned keyboard inhibit problem is described in greater detail in a reference book entitled, xe2x80x9cPC KEYBOARD DESIGNxe2x80x9d, by J. Konzak, and published by Annabook. In the configuration of FIG. 1, the inhibit problem could cause decoded bar code data to be lost, ignored, corrupted, or misread once the PC or laptop interrupts communication. With the advent of multitasking operating systems, sophisticated network operating systems, and dual-keyboard port laptops and PC""s, the problem worsens. Some of these operating systems interrupt keyboard port communications on a frequent and periodic basis, such as once every ten milliseconds. Of course, in operational environments where the keyboard controller port is not used with an auxiliary input devices, the computer keyboard will sense this stoppage of communications and retransmit the scan code after the PC releases its halt or inhibit of the keyboard. Existing bar code scanners are not so equipped. If a data transmission from a bar code scanner is interrupted, the scanner has no mechanism by which to ascertain whether or not a data entry error has occurred.
Pursuant to prior art techniques, bar code scanners had not monitored the inhibit signal because the decoded bar codes were wedged into the transmitted data for brief periods of time, relative to typed-in keyboard data. Also, as a practical matter, the keyboard BIOS virtually never inhibits the keyboard during scan code transmission. Any problems that may have been encountered were handled by changing certain programmable parameters such as inter-character delays or inter-scan-code delays.
A bar code scanner is equipped with a keyboard emulation mechanism so as to provide an enhanced interface to a keyboard controller port of a computing device such as a personal or laptop computer. The keyboard emulation mechanism eliminates the necessity of connecting an actual computer keyboard to the port by responding to the computing device""s standard power-on diagnostic procedure as if it were effectively an electrical equivalent of a computer keyboard.
Pursuant to a further embodiment of the invention, the keyboard emulation mechanism is equipped to detect a keyboard inhibit signal at the keyboard controller port. This inhibit signal may be generated by the computing device. If the keyboard emulation mechanism detects a keyboard inhibit signal while a data byte is being transmitted to the keyboard controller port, the keyboard emulation mechanism stops transmitting the data byte, waits for the inhibit signal to cease, and then retransmits the data byte to the keyboard controller port. This retransmission process is repeated up to a specified number of times, so as to provide additional opportunities for the data byte to be inputted to the keyboard controller port if the port is momentarily disabled by the keyboard inhibit signal. For many applications, it is advantageous to repeat the retransmission process up to three times for a given data byte. If the data byte is still not successfully received after the third attempt, the process is no longer repeated.
Pursuant to a still further embodiment of the invention, the keyboard emulation mechanism keeps track of status indications transmitted by the computing device and related to the status of one or more indicators on a computer keyboard. These indicators may be provided in the form of one or more LED lamps indicative of the status of the Caps-lock, Num-lock, and Scroll-lock keys. The keyboard emulation mechanism also keeps track of the transmission protocol currently in use, such as make-Break,Make-Only, AT or PS2-type scan-code transmission protocols. These status indications and transmission protocols may vary, depending upon the keyboard country type selected, and are maintained by the keyboard emulation mechanism so that the bar code scanner will transmit accurately to the computing device.
The keyboard emulation mechanism may be provided in the form of enhanced software, firmware, and/or programming instructions. This software, firmware, and/or operating instructions can be configured for use with presently-existing keyboard wedge scanners, as well as any of various scanners which may be developed in the future. One purpose of the software, firmware, and/or operating instructions is to accurately transmit a bar code on a transmission line that is subjected to possible halt or inhibit signals issued by the computing device It should be noted that any number of sources contained within the computing device could generate these inhibit signals. When a data byte is received at the keyboard port, this byte, which may represent all or part of a decoded bar code, is optionally displayed on a monitor coupled to the computing device.